Section 6 Feedback Loop Auto-Processing

LISTSERV is able to automatically process Feedback Loop reports, which are sent automatically by some ISPs, such as AOL and Yahoo!, to organizations that are on their whitelist. Once configured, LISTSERV automatically parses the reports and implements the actions required by the whitelist agreement. This helps preserve whitelist status and reduce the number of spam complaints from subscribers.

Use of this feature assumes you already have a feedback loop in place as part of your ISPs whitelist agreement and are able to redirect the feedback loop reports to a new address.

6.1 Configuring the SPAM_FEEDBACK_PROBE Variable

The SPAM_FEEDBACK_PROBE variable defines the domains for which to enable automatic processing of Spam Feedback Loops.

There are two steps in configuring automatic feedback loop processing.

1.	Define this configuration variable with the space-separated domain names for which to enable Spam Feedback Loops, for example AOL.COM or YAHOO.COM.

2.

Create a LISTSERV list dedicated to feedback loop processing. It can be configured as you wish as long as the special addresses from which the spam reports are sent are authorized to post to the list. Test the list carefully to make sure that archiving is working properly and that the list will not send any replies back. Then, add Misc-Options= PROCESS_SPAM_FEEDBACK to the list configuration to activate automatic report processing.

If the message is recognized as a spam report and refers to a message that originated after you set the SPAM_FEEDBACK_PROBE configuration option, LISTSERV will:

1.	Immediately delete the user from all LISTSERV lists, on the first spam report. This does not include Dynamic Query Lists, which are managed outside LISTSERV.

2.	Not send any notification to the user.

3.	Add the user to the spam feedback list with the NOMAIL option to keep a record of who has lodged spam complaints. The subscription date is set to the date of the first complaint and the last activity date is set to the date of the last complaint.

4.	Log a SPAM_COMPLAINT record to the list's change log, if one has been defined. You can use this information to remove the user from Dynamic Query Lists, if you have any such lists.

This ensures that no further mail will be sent to the user and minimizes the risk for further complaints (although experience has shown that people sometimes find old messages in their mailbox days or weeks later, which can lead to a handful of additional spam reports).

To define in the Web Interface, click on Server Administration, select Site Configuration, and then finally select Site Configuration. The Site Configuration wizard opens. Click on the Anti-Spam tab, and then define SPAM_FEEDBACK_PROBE. For example:

SPAM_FEEDBACK_PROBE=AOL.COM

This configuration variable is not set by default.

6.2 Configuring the SPAM_FEEDBACK_ACTION Configuration Variable

The SPAM_FEEDBACK_ACTION variable is now available and documented in the Site Configuration wizard on the Anti-Spam tab. This variable determines what actions to take when LISTSERV receives spam complaints through Feedback Loops.

By default, when a spam complaint is received through a Feedback Loop, LISTSERV will:

1.	Immediately delete the user from all LISTSERV lists, on the first spam report. This does not include Dynamic Query Lists, which are managed outside LISTSERV.

2.	Not send any notification to the user.

3.	Add the user to the spam feedback list with the NOMAIL option to keep a record of who has lodged spam complaints. The subscription date is set to the date of the first complaint and the last activity date is set to the date of the last complaint.

4.	Log a SPAM_COMPLAINT record to the list's change log, if one has been defined. You can use this information to remove the user from Dynamic Query Lists, if you have any such lists that may contain users.

To define in the Web Interface, click on Server Administration, select Site Configuration, and then finally select Site Configuration. The Site Configuration wizard opens. Click on the Anti-Spam tab, and then define SPAM_FEEDBACK_ACTION.

Possible definitions include (all space-separated actions are taken in turn):

•	DELETE: The user is deleted from all LISTSERV lists.

•	EXCLUDE: The user is added to the spam feedback lists with the NOMAIL option.

•	SERVEOFF: The user is served off.

•	SERVEDROP: The user is served off with the DROP option.

•	NONE: No action is taken other than logging an entry to the list's change log (if defined).

•	LOGALL: An advanced option for customers operating multiple LISTSERV instances, which collects a central copy of all spam reports and forces them to be logged on that instance even if the reports are for another instance.

This default value is DELETE EXCLUDE.

6.3 Configuring the SPAM_FEEDBACK_EXCLUDE Variables

In LISTSERV 16.0, it is now possible to exclude subscribers who have complained about spam from your organization. At this time, the exclusion is only allowed via DISTRIBUTE; this does not include administrative messages.

Important: The SPAM_FEEDBACK_EXCLUDE variables are for advanced users and are only available when LISTSERV is in Expert Mode.

To define in the Web Interface, click on Server Administration, select Site Configuration, and then finally select Site Configuration. The Site Configuration wizard opens. Click on the Anti-Spam tab, and define the following:

•

SPAM_FEEDBACK_EXCLUDE_LIST – This variable tells LISTSERV to exclude all of the subscribers of the Spam Feedback Loop list in question from future bulk mailings, even if subscribed to a list or targeted for a mailing via LISTSERV Maestro or home-made DISTRIBUTE job or any other channel. This does not blackhole administrative messages; therefore, the users can still receive confirmation cookies necessary to execute commands and so on.

To enable this setting, enter the name of the Spam Feedback Loop list as the value of this configuration variable. For example, for a list named Spam-Feedback:

SPAM_FEEDBACK_EXCLUDE_LIST=SPAM-FEEDBACK

This configuration variable is not set by default.

Note: L-Soft does not recommend defining multiple lists. For maximum performance, this variable is only intended for use with one list. Then, you can ADD anyone that you want to exclude to this list. (Make sure to set the options for this list to NOMAIL.)

•	SPAM_FEEDBACK_EXCLUDE_ALLOW – This variable enables LISTSERV instances on this CIDR range to query the exclusion list managed by this LISTSERV instance. Use this setting in the instance running the Spam Feedback Loop, and in this instance only. For example:

SPAM_FEEDBACK_EXCLUDE_ALLOW=212.247.25.0/25

This configuration variable is not set by default.

•	SPAM_FEEDBACK_EXCLUDE_SERVER – This variable should be set in the other LISTSERV instances with the hostname of the instance that operates the Spam Feedback Loops. The optional port number must match the TCPGUI port for that instance if you are not using the default value. For example:

SPAM_FEEDBACK_EXCLUDE_SERVER=LISTSERV.XYZ.COM:80

This configuration variable is not set by default.

6.4 Testing

L-Soft strongly advises a testing period during which individual spam reports are manually forwarded to the list. It is important to forward the messages in such a way that they are received by the list with the same special MIME structure that identifies spam reports. The sender is immaterial as long as it is authorized to post to the list.

By default, when a spam complaint is received through a Feedback Loop, LISTSERV will:

1.	Immediately delete the user from all LISTSERV lists, on the first spam report. This does not include Dynamic Query Lists, which are managed outside LISTSERV.

2.	Not send any notification to the user.

3.	Add the user to the spam feedback list with the NOMAIL option to keep a record of who has lodged spam complaints. The subscription date is set to the date of the first complaint and the last activity date is set to the date of the last complaint.

4.	Log a SPAM_COMPLAINT record to the list's change log, if one has been defined. You can use this information to remove the user from Dynamic Query Lists, if you have any such lists that may contain users.

This ensures that no further mail will be sent to the user and minimizes the risk for further complaints.

You can verify the operation of the feature on the LISTSERV log. Once you are comfortable with your setup, you can redirect all of the ISPs spam reports to the list so that they are processed without manual forwarding.

6.5 Challenges and Advice

You can expect a few challenges once you have activated automatic processing. Here is some advice on how to deal with the most common issues.

•

Be patient. Initially, most incoming spam reports will refer to messages created before the SPAM_FEEDBACK_PROBE= setting was defined in the LISTSERV configuration. It may take a day or two for automatic processing to start kicking in. You will continue to see unprocessed messages for at least one month after enabling the feature. There is nothing you can do about it, other than wait for these old messages to have “expired” from the pipeline.

•

Many false positives. L-Soft’s experience has been that many spam reports are sent erroneously. We have seen list owners with certain ISP accounts report their own lists as spam! It is exceedingly easy for a user to generate a spam report without even realizing it; for instance, exiting the mail interface in a hurry will silently generate a spam report for any unread messages automatically sent to the junk mail folder by some ISP filters.

•

Complaints from certain ISP users, such as AOL. For instance, the heavy-handed “one strike and you’re out” rule is not popular with AOL users who have erroneously generated a spam report. If anything, the lack of notification is even less popular. AOL users may get upset and blame your organization. But, in reality, you do not have a choice in the matter. The terms of AOL’s whitelist agreement require “one strike and you’re out” and forbid notification. You have a choice between being heavy-handed and not being on the whitelist, which in practice would promptly cause all of your mail to AOL to be blocked and all AOL users to be deleted. Be prepared to write a FAQ for your list on this topic.

•

Complaints from list owners. It is convenient for most list owners to refer to an organization-wide policy that in turn refers to the legal terms of an ISP’s whitelist agreement, which most reasonable people will understand must be followed. But some list owners will complain that they are unable to re-add users that have been served off. Be prepared to make a policy on serving these users back. It is up to you as whitelist agreements are silent on that issue.

•

Spam reports from reinstated users. You will find that many reinstated users continue to issue spam reports because they simply do not understand what causes these spam reports to be sent. Until they know what they must do differently, they will keep generating spam reports that hurt your deliverability – and blaming LISTSERV and you for the false positives. This is why it is important to keep archives of all your spam reports. Once the user is convinced that you did receive a new spam report, the problem will be transferred to ISP’s help desk, which in most cases is able to help the customer disable these reports.

•

Lax or tough? One of the decisions you will have to make is whether to reinstate all users simply for the asking, or only if they petition you in writing and agree not to send any further reports, or never. It is important to understand that every spam report is a petition by a customer to terminate your organization’s access to that particular ISP. Of course, it takes a lot of reports for this to happen, but there is absolutely no difference between voluntary and involuntary spam reports. The risk, if you keep reinstating anyone who asks, is that you keep receiving spam reports from users who are unable to learn how to turn them off, and that your deliverability will suffer. By trying to help a handful of users who share their account or are just not very good with computers, you may end up hurting thousands of users who have meticulously followed instructions to turn off spam reports for your organization.

6.6 Future Direction

L-Soft would like to receive customer input about the reinstatement issue.

At this point, L-Soft will not provide configuration options to loosen the “one shot and you’re out” rule, because it is a legal requirement of the AOL whitelist agreement. Usage of the automatic feedback loop processing feature is entirely optional; nobody is locked in to the new automatic processing feature, but it can only be used in compliance with AOL’s terms. L-Soft may revisit this position if AOL changes its whitelist terms. L-Soft believes that the way to move forward on this issue is to encourage AOL users to complain to AOL about the rule, rather than try and configure LISTSERV to ignore it. Like any business, AOL is likely to listen to its customers. AOL has historically been willing to listen to issues such as this one, at least once it saw that there was widespread concern and not just a handful of vocal complaints. Give AOL a chance to set this straight.

6.7 Known Issues and Restrictions

The following known issues and restrictions exist:

•	Preamble inserted in original message. The little preamble LISTSERV inserts on spam reports it has successfully processed is often also inserted inside the original message. This is an artifact of the current implementation that may be removed in the future.

 

L-Soft international, Inc.

1-800-399-5449